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Sir: 

Responsive to the Office Action dated April 26, 2002, Applicant respectfully requests 
reconsideration and withdrawal of the rejections applied to claims 1-21 for all of the reasons 
enumerated immediately below. 

Claims 1-21 are pending in the application. 

The Office Action rejects claims 1-21 under 35 U.S.C. § 102(e) as being anticipated by 
England (U.S. Patent No. 6,144,991). Thus, the sole question regarding patentability of the instant 
application is whether any of pending claims 1 -2 1 is anticipated by the ' 99 1 patent. It is respectfully 
submitted that the answer to this question has to be a resounding negative. The rationale for 
Applicant's assertion will be set forth in detail below. However, before traversing the specific 
rejections. Applicant will present a brief explanation of the claimed invention and the '991 patent. 
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L SUMMARY OF THE PRESENT INVENTION 

The Common Collaboration Environment (CCE) application (hereinafter White Board) 
disclosed in the above-identified application allows a large organization to solve certain 
interoperability problems while satisfying collaboration requirements and, thus, satisfy all of the 
following goals: 

a. Display tactical and strategic information on any vendor's modern commercial off 
the shelf (COTS) equipment without modification; 

b. Permit display of active moving content, as well as incorporation of active hyperlinks 
and active GUIs. 

c. Requires that all users log into a White Board secure server, allowing each client to 
be uniquely identified and allowing a system administrator to "kill" White Board 
clients, i.e., forcing the White Board client offline; and 

d. Deliver a technology for providing training both afloat and ashore, independent of 
the system on which training is being provided and independent of the training 
facilities available. 

See page 13, lines 6-19. 

Fig. 2 illustrates a computer system 1 that includes servers 100a through lOOn, object 
generators 200a through 200m, and computers 300a-300r. All of the servers lOOa-lOOn, the object 
generators 200a-200m and the computers 300a-300r are operatively connected to one another via a 
communications link 400. Each of the machines lOOa-lOOn and 200a-200m includes a processor, 
working memory, a storage device such as a hard disk and a commimications device, e.g., a network 
interface card. Computers 300a-300r can include desktop computers, laptop computers and/or 
workstations in any mix; thus, these computers include a central processing unit, a graphic display 
processor, the graphic display device, e.g., monitor, a communications device and several memories 
including both solid state memories, i.e., random access memory (RAM) and a hard disk drive. Link 
400 can be any one of a local area network (LAN), a wide area network (WAN), etc. See page 13, 
line 26, through page 14, line 15. 

In Fig. 3, the computer system 1 is illustrated as including a server host 100, an application 
host, i.e., object generator, 200, and client host computers 300a and 300b, all of which are 
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interconnected to one another via a LAN or WAN 400 (hereinafter LAN 400). The server host 100 
provides a Web server 101, a White Board server 102, and a generated object server 103. The 
appHcation host 200 can be another computer running a predetermined program to generate an obj ect 
which can be accessed by the users operating client hosts 300a and 300b. Ahematively, the 
appHcation host 200 can be a file server storing files such as maps and satelUte images. Client hosts 
300a and 300b provide a JAVA™ enabled web browser, i.e., a web browser implementing a 
JAVA™ virtual machine, while the Web server 101 on server 100 stores a web page and associated 
White Board Applet tag. See Fig. 5 for an exemplary web page listing. When the downloading of 
the web page from the Web server 101 to the client host 300a, i.e., the web browser on the user's 
computer, is completed, the White Board Applet is executed to thereby display the White Board on 
the user's computer. See page 14, line 24, through page 15, line 10. 

When the White Board Applet 301a on client host 300a runs, it will connect to the White 
Board Application Server 102 running on server 100 while displaying all of the windows for the 
client-side White Board display, i.e., the White Board GUI will be presented to the user. The user 
can then run the White Board application, which can transfer data between the White Board server 
102 running on server 100 and other White Board clients, i.e., computer 300b. As discussed in 
greater detail below, the object generator 200 can provide information, i.e., an image, which may be 
an active image, for display on the White Boards presented on computers 300a and 300b via 
generated object server 103. Fig. 4 illustrates the White Board rurming on a computer 300 resulting 
fi-om the collaboration of several users remotely located with respect to one another. See page 15, 



Although the White Board server 102 and the generated object server 103 are stand alone 
applications, their functions were separated as an aid to understanding the White Board system 
operation. A single White Board server could provide both server functions when system 
requirements do not mandate that the objects generated by object generator 200 be displayable 
irrespective of White Board server status. See page 20, lines 17-22. 

The White Board is started, operated and shutdown as illustrated in the high level flowchart 



lines 11-23. 
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of Fig. 8. During step SI, the user on computer 300a, for example, connects to the web sever 101 
operating on server 100 via LAN 400. The v/ob server 101 downloads a web page containing the 
White Board Applet tag to the JAVA'^^-enabled web browser running on computer 300. When the 
JAVA™-enabled web browser encounters the White Board Applet tag, the White Board client applet 
is dovmloaded from server 100 to computer 300 during step 82. During step S3, the White Board 
Client 301 initializes and requests login information from the user, as a security precaution. During 
step S4, the White Board client 301 uploads login information, e.g., user name and password, to 
White Board server 1 02 via LAN 400. The White Board server 1 02 then determines whether the user 
attempting to login is an authorized user or not during step S 5 . Li the event that the login information 
is acceptable, all features of the White Board client 301 ruiming on computer 300 are activated 
during step S6. In the event that the user's identity is not acceptable to the White Board server 102, 
the White Board client shuts down during step S9. See page 23, line 18, through page 24, line 2. 

Once the White Board client 301a becomes available for use at step S6, either the user of the 
White Board client 3 0 1 a or another user operating White Board client 301b updates the White Board 
client 301a during step S7, as discussed in greater detail below. Each change to the White Board 
client 301a triggers a check to determine whether the White Board client is to be shut down during 
step S8. In the answer at step SB is NO, the users continue to cooperatively update the White Board 
client 301a; when the answer is NO, the White Board client 301a is shut down at step S9. See page 
24, lines 4-13. 

The user draws on the White Board client 30 1 a as illustrated in Fig. 9 A, which is a flowchart 
reflecting operations from the White Board user's perspective. During Step SIO, the user selects the 
drawing object pull down menu illustrated in Fig. 7. Then, the user selects one of the objects by 
executing one of the steps SI 1-S16 to add to the White Board display. A detailed discussion of 
adding non-intuitive objects to the White Board display area will be presented below. During step 
SI 7, the user determines whether to add other objects to the White Board display area. If the user 
desires to add other objects to the White Board display, an additional one of steps S11-S16 is 
executed. When the determination of step S 1 2 is NO, the user logs out of the White Board client 301 
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during step S 1 8, i.e., the White Board cUent 301 shuts down during step S 1 9. See page 25, Unes 1 -9. 

From a programmers perspective, the White Board cUent 301 operates as illustrated in Fig. 
9B. When the White Board client 301 starts at step S20, the White Board client waits for a "mouse 
down" event, since the exemplary White Board client is a JAVA'^^ applet, i.e., a event driven 
application. Selection of an object from the resource list depicted in Fig. 7 creates an empty wrapper, 
which wrapper is assigned a unique identifier and which wrapper contains the selected object label. 
Thus, when a mouse down event occurs at step S2 1 , step S22 is performed to determine whether the 
object is a graphic, i.e., a bit map, object. When the answer is NO, another check is performed to 
determine whether the object can be instantiated, i.e., created, during step S24. When the answer at 
step S24 is YES, the selected object is instantiated; when the answer is NO, an error message is 
displayed during step S29 and the White Board client is stopped at step S30. See page 25, lines 11- 
21. 

When the answer at step S22 is YES, i.e., is the object is a graphic object, or after the object 
is instantiated at step S24, the information needed to regenerate the selected object is placed into the 
above-mentioned wrapper, to thereby generate a wrapper object. As mentioned above, the wrapper 
includes a unique identifier so that the wrapper object can be locally identified, used by the local 
White Board client 301 and globally identified to prevent collisions with other wrapper objects. 
During step S26, the wrapper object is added to a vector holding all wrapper objects drawn on the 
local White Board client 301. Using the thus generated vector, the wrapper object is displayed in the 
White Board client 301 . When a "mouse up" event occurs, the wrapper object is transmitted to the 
White Board server 1 02 over LAN 400 for relay to the other active White Board clients, as discussed 
in greater detail with respect to Fig. 1 1 . It should be noted that "mouse up" should be understood to 
equate to "hard return" with respect to text, since the wrapper object containing text is transmitted 
to White Board server 102 when a hard return is sent by the user. See page 25, line 23, through page 
26, line 5. 

In terms of system architecture, every White Board Client 301 connects to a shared White 
Board server 1 02. It will be noted that no White Board client can communicate directly with another 
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White Board client. White Board clients only communicate with the White Board server both for 
reasons of security and for reasons dictated by the programming environment. From a security 
perspective, the White Board system was developed to permit the White Board server to filter the 
data, wrapper objects, by privilege. Additionally, in order to insure traceability, i.e., the ability to 
retrace or recreate the steps by which the White Board display was generated, it is necessary to 
maintain a central logging and data storage capability. Moreover, it will be appreciated that Java 
applets further reinforce this security mechanism. The White Board client, as an unsigned applet, can 
only make a network connection to the machine address that served to it by the user's web browser. 
See page 27, lines 1-11. 

When a user does something on the White Board or when the user chats with other White 
Board users, the White Board client sends the action via a command up to the White Board server. 
The White Board server then relays the command on to the other White Board clients, assuming that 
the other White Board clients have the correct security privilege to receive and execute the 
command. Every command is time stamped by the White Board server and contains the action, its 
privilege, the originating user, machine address, port number, and object specific data sufficient to 
recreate the same object remotely. In other words, the White Board server time stamps each wrapper 
object so that the White Board system can afterwards determine when the wrapper object was created 
and when the wrapper object was modified, and stores a copy of the wrapper object on the White 
Board server (or at a White Board server specified location). Given that information, it will be 
appreciated that a complete history may be logged and replayed. It will also be appreciated that each 
White Board client maintains its own unique copy of the White Board based on the user's maximum 
privilege . See page 27, line 25, through page 28, line 8. 

Fig. 1 1 illustrates the operation of White Board server 102 receiving both objects defined by 
White Board client 301a and an active track generated by computer 200a via LAN 400. In the 
illustrated example, the White Board server 102 attempts to transmit the object and the active track 
to White Board clients 301b and 301c, also via LAN 400. The White Board server 102 receives the 
object transmitted by White Board client 301a running on computer 300a during step S3 1 . A check 
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is then performed during step S32 to determine whether all of the White Board clients, e.g., White 
Board clients 301a, 301b and 301c, have the same privilege level. When the answer is YES at step 
S32, the White Board server 102 shifts to a multi-cast mode of operation during step S33 and relays 
the object to White Board clients 301b and 301c by simultaneously performing steps S36 and S39. 
When the answer at step 832 is NO, the White Board server 102 performs a check at step S34 to 
determine whether the object(s) to be transmitted to White Board client 301b has a privilege level 
less than or equal to the privilege level assigned to White Board client 301b. When the answer at step 
834 is NO, the routine jumps to step 835, wherein the object is indicated as being ignored and the 
routine loops back to the beginning of step 834 to await the next object. In the event that the answer 
is YES, the received object is then transmitted to the active port corresponding to respective White 
Board client 300b during step S36. See page 36, line 17, through page 37, line 2. 

When the answer at step S32 is NO, the White Board server 1 02 performs a check at step S37 
to determine whether the object(s) to be transmitted to White Board client 301c has a privilege level 
less than or equal to the privilege level assigned to White Board client 301c. When the answer at step 
837 is NO, the routine jumps to step 838, wherein the object is indicated as being ignored and the 
routine loops back to the beginning of step 837 to await the next object. In the event that the answer 
is YES, the received object is then transmitted to the active port corresponding to respective White 
Board client 300c during step S39. See page 37, lines 4-10. 

Still referring to Fig. 1 1 , the generated object server 103 receives an object, e.g., active track 
information, from computer 200a during step 840. It should also be noted that the active track 
information can be either an active track image itself or update information for an established active 
track object. In any event, the received object is then transmitted to the active ports corresponding 
to respective White Board clients 300b and 301c during steps 836 and 839. See page 37, lines 12-18. 

It should be mentioned that the object with too high a privilege, i.e., a secret object being 
transmitted to a White Board server 301b with a confidential classification, can be treated in any 
number of ways to ensure that the object is not transmitted to the White Board server 301a. All of 
these methods, e.g., flagging the object, can be collectively termed security filtering. It should also 
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be mentioned that the chat function, which allows all of the White Board clients to send real time 
text to all connected clients, can be security filtered as well. See page 37, line 26, through page 38, 
line 5. 

n U,S. Patent No. 6.09M12 

The sole applied reference discloses a guided telecommunications system. As illustrated in 
FIG. 12, which is a high-level block diagram of the Hamelin system 1200, a system for managing 
interactions between users (i.e., a guide and one or more clients) in a browser-based 
telecommimications network includes a system (piper) server 502; a HTTP server 1204; at least one 
guide system 1206; and at least one client system 1208. Communication via the browser-based 
network among servers 502 and 1204 and guide system 1206 and client system 1208 uses packets 
propagating serially based upon the TCP/IP protocol. However, guide system 1206 only 
communicates directly with HTTP server 1204 and system server 502; server 502 only 
communicates directly with guide system 1206 and client system 1208; client system 1208 only 
directly communicates with servers 1204 and 502; and, finally, server 1204 only communicates 
directly with systems 1206 and 1208. Accordingly, system 1200 represents a logical model for the 
inter-element communications, with the direct communication paths shown as separate logical paths. 
Piper server 502 communicates using a Web Guide Protocol (WGP) which is written on top of 
TCP/IP. HTTP server 1204 communicates using the HTTP protocol. Guide system 1206 and client 
system 1208 both communicate using TCP/IP. See col. 14, line 65 through col. 15, line 29. 

In general, piper server 502 acts as an intermediary between guide system 1206 and client 
system 1208. In general, the guide initiates instructions. These instructions are to load framesets, 
frame layouts, and/or frame contents such as Web pages, collaborative tools and/or Internet 
Resources. These instructions are commimicated to piper server 502. Piper server 502 forward these 
instructions to all connected client systems through their client-side components. Each client-side 
component 904 orders its associated client Web browser 1 3 1 2 to implement the guide's instructions. 
See Col. 26, lines 20-29. 
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The *991 patent also discloses that while generally the frames displayed on the client 1208 
are generated via commands issued by the guide 1206 and relayed via the piper server 502, it is 
possible to effect the display of the guide system 1206 and other clients 1208 via commands . For 
example, as illustrated in FIG. 39, the user sometimes clicks and drags a mouse to draw a line. When 
the mouse button is released, director application 1 306 or client-side component 904 sends the WGP 
command: "LINE COLOR 3 N XI Y1X2Y2" to piper server 502 where color is the desired color for 
the display of the whiteboard, forwards the WGP command to all connected client systems, to cause 
each client system draws the line segments on their respective Web browsers. See col. 33, lines 19- 
33. Altematively, the guide can construct a collaborative tool such as a shared pointer that both the 
client and guide will view simultaneously on their Web browsers. Either party can "click on and 
drag" the pointer. If either party moves it, it moves on all display screens for the PC systems (i.e. 
guide PC system(s) and client PC system(s)). The shared pointer responds to commands such as: 
POINTER ON (to make the pointer visible); POINTER OFF (to make the pointer invisible); 
POINTER COLOR (any color available in the spectrum such as RED, GREEN, BLUE, PINK, 
PURPLE, or YELLOW); and POINTER MOVE X, Y (to move POINTER to position X, Y). See 
Col. 31, line 57, through Col. 32, line 20 

III. PREFATORY MATTERS 

The Office Action dated April 26, 2002, stated that the "arguments filed on 4/5/02 are not 
deemed persuasive." Applicant objects to any examining procedure applied in formulating the final 
rejection where the rejection is based on the Applicant's ability to convince the Examiner that his 
original rejection was erroneous. The concept of a prima facie case of anticipation is not a segmented 
concept; the decision-maker must start over when rebuttal evidence or argument is submitted after 
a prima facie case of anticipation has been established. In determining whether the Applicant has 
the burden of going forward with rebuttal arguments, the entire path to a decision must be retraced; 
thus, the earlier decision should not be considered as set in concrete with the Applicant's rebuttal 
evidence / argument evaluated only on its knockdown ability. A prima facie case of anticipation is 
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a legal conclusion, not a fact; facts established by rebuttal evidence and rebuttal arguments must be 
evaluated along with the facts on which the earlier conclusion was reached, not against the 
conclusion itself See In re Rhinehart ^ 189 U.S.P.Q. 143 (CCPA 1976). 

Moreover, Applicant clearly disputes the conclusion set forth in the Office Action that the 
Examiner has established a "prima facie" case of anticipation. More specifically. Applicant has 
clearly demonstrated that the First Office Action had not established a "prima facie" case of 
anticipation, since at least three of the express limitations common to independent claims 1,5, and 
13 are completely missing from the '991 patent. The Applicant respectfully submits that the 
deficiencies that prevent the first Office Action from establishing a "prima facie" case of anticipation 
is not cured in the Final Office Action. 

Furthermore, the previous and current Office Actions asserted that claims 1-21 were clearly 
anticipated by England (the '991 patent) and then proceeded to provide a cursory analysis which 
utterly failed to address the specific limitations set forth in independent claims 1 , 5 and 13, and only 
addressed the gist of the recitations of dependent claims 9, 1 1 , 1 2, 1 7, 1 9, and 20. Dependent claims 
2-4, 6, 8-10, 14-16, 18, and 21 are not even addressed. 

Applicant respectfully submits that this summary treatment of the pending claims is 
tantamount to applying a rule of thumb permitting the Examiner to excise stated limitations fi*om 
the claim and then examine the residue. As the Court of Appeals of the Federal Circuit held in In 
re Ochiai . 37 U.S.Q.P.2d 1 127,33 (Fed. Cir. 1995): 

"The use of per se rules, while undoubtedly less laborious than a searching 
comparison of the claimed invention -including all its limitations- with the teachings 
of the prior art, flouts section 103 and the fundamental case law applying it. Per se 



1 While In re Rhinehart addressed itself the "prima facie" obviousness, the legal principle is 
equally applicable to consideration regarding anticipation. There is no directions in the M.P.E.P. 
on holding in the case law that require any deference whatsoever to be paid to the rejection set 
forth in a First Office Action. Patentability is always determined with respect to record in its 
entirety. 
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rules that eliminate the need for fact-specific analysis of claims and prior art may be 
administratively convenient for PTO examiners and the Board. Indeed, they have 
been sanctioned by the Board as well. But reliance on per se rules of obviousness is 
legally incorrect and must cease. Any such administrative convenience is simply 
inconsistent with section 103, which, according to Graham and its progeny, entitles 
an applicant to issuance of an otherwise proper patent unless the PTO establishes that 
the invention as claimed in the application is obvious over cited prior art, based on 
the specific comparison of that prior art with claim limitations. We once again hold 
today that our precedents do not establish any per se rules of obviousness, just as 
those precedents themselves expressly declined to create such rules." [Emphasis 
added.] 

Applicant submits that while the C.A.F.C.'s decision in Ochiai treats an obviousness 
rejection, the rationale is no less applicable to any other rejection based on a different section of the 
patent law, e.g., 35 U.S.C. § 102(e), since there are specific case law provisions detailing the 
minimum requirements of such rejections. For example, it is well settled that anticipation requires 
that all of the elements and limitations of the claim are found within a single prior art reference. It 
is also well settled that there must be no difference between the claimed invention and the reference 
disclosure, as viewed by a person of ordinary skill in the field of the invention. See Scripts Clinic 
V. GenentechJnc. 18U.S.P.Q.2d 1001, 10 (Fed. Cir. 1 991). In ether case, the C.A.F.C. requires that 
all elements and limitations in a claim be considered. Any rule of thumb or Patent Office practice 
that permits less than all of the elements and limitations of a claim to be considered in rejecting a 
claim flies in the face of decided case law. 

IV. CLAIMS 1-21 ARE NOT ANTICIPATED BY THE '991 PATENT 

As discussed both in the previously filed Amendment of April 5, 2002, and immediately 
above, anticipation requires the presence in a single prior art disclosure of all elements of a claimed 
invention arranged as in the claim. See Connell v. Sears, Roebuck & Co. , 220 U.S.P.Q. 193, 198 
(Fed. Cir. 1983). Thus, an invention is anticipated if the same device, including all the claim 
limitations, is shown in a single prior art reference. Every element of the claimed invention must be 
literally present, arranged as in the claim. The identical invention must be shown in as complete 
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detail as is contained in the patent claim. Thus, a rejection for anticipation or lack of novelty 
requires, as the first step in the inquiry, that all the elements of the claimed invention be described 
in a single reference. Richardson v. Suzuki Motor Co. . 9 U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989), 
cert denied, 110 S.Ct. 154 (1989). Further, the reference must describe the applicant's claimed 
invention sufficiently to have placed a person of ordinary skill in the field of the invention in 
possession of it. Akzo N.V. v. United States Int'l Trade Comm'n . 1 U.S.P.Q.2d 1241, 1245 (Fed. Cir. 
1986), cert denied, 482 U.S. 909 (1987); In re Coken 175 U.S.P.Q. 26, 29 (C.C.P.A. 1972). 

Moreover, anticipation requires that all of the elements and limitations of the claim are found 
within a single prior art reference. There must be no difference between the claimed invention and 
the reference disclosure, as viewed by a person of ordinary skill in the field of the invention. See 
Scripts Clinic v. Genentech, Inc. , 18 U.S.P.Q.2d 1001, 10 (Fed. Cir. 1991). 

The pending application and the '991 patent are discussed in detail above. 

Application respectfully submits that the Final Office Action has not set forth a "prima facie" 
case of anticipation, since the '991 does not disclose: 



generating objects including an active hyperlink object; 

transmitting the generated objects including the active hyperlink object; 

accumulating the generated objects included the active hyperlink object; 

filtering the accumulated objects including the active hyperlink object, to thereby 

permit selective retransmission of the objects to respective ones of the other users; 



which limitations are common to all of independent claims 1, 5, and 13. Moreover, independent 
claim 1 3 includes numerous limitations not found in either in independent claims 1 and 5 and clearly 
lacking in the '991 patent. 

Independent claim 1, as amended, recites: 

1. A method facilitating collaboration between a plurality of users of 
incompatible hardware and/or operating systems, comprising: 
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selectively generating predetermined objects, text objects, active hyperlink 
objects, and freehand drawing objects, which are displayable at user-selected 
locations on a White Board screen of one of the users; 

transmitting all generated ones of the predetermined, the active hyperlink, the 
text, and the freehand drawing objects for selective distributions to each of the other 
users; 

accumulating the predetermined, the active hyperlink, the text, and the 
freehand drawing objects; and 

filtering the predetermined, the active hyperlink, the text, and the freehand 
drawing objects to thereby permit selective retransmission of the predetermined, the 
active hyperlink, the text, and the freehand drawing objects to respective ones of the 
other users. 

It is respectfully submitted that since the '991 patent does not disclose or even suggest the 
generating, transmitting, accumulating, and filtering steps, the '991 patent cannot anticipate the 
inventive method of claim 1. 

However, before addressing the specific steps recited in claim 1, Applicant wishes to focus 
on the wording of the preamble, i.e., "[a] method facilitating collaboration between a plurality of 
users." The rationale set forth in the Final Office Action in rejecting claims alleged that a filtering 
step is disclosed by England is as follows" 

"Applicant also alleges that England does not teach filtering information because all 
users coupled to the piper server receive the same information. 

The examiner disagrees. England's piper server is capable of creating and maintaining 
several independent sessions at the same time (see col 11, lines 21-33). In other 
words, a user in one conference session does not necessary receive data sent by other 
users in another conference. Thus, when the piper server receives an object from a 
user, it forwards the received object to all (active) participating users in a select 
session, not to all users in all sessions managed by the piper server (see col 29, lines 



However, the users in the Examiner 's postulated first session are not collaborating with 
users of a second session. While there may be two groups of users in two separate session connected 
to the piper server 512, the fact that the second group does not see the objects generated by one or 



47-67). 



35 
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more users in the first group is not dispositive of anything, since the members of the second group 
are not collaborating with members of the first group. Moreover, the Examiner admits, in the 
rationale supporting the rejection, that "when the piper server receives an object from a user [in the 
first session], it forwards the received object to all (active) participating users in a select [first] 
session." thus, the Final Office Action admits that all collaborating users receive all transmitted 
objects, and not selected, i.e., filtered, one of the objects. 

Turning now to the express wording of claim 1, it is respectfiiUy submitted that the '991 
patent does not disclose or suggest generating an active hyperlink object. The Whiteboard disclosed 
by the '991 patent is illustrated in Fig. 1 1 and discussed at column 13, lines 35-50. In particular, the 
'991 patent states that Fig. 1 1 shows another illustrative embodiment of the guide's display screen 
when a collaborative tool such as a shared whiteboard is implemented and the frame layout in the 
remotely displayable frames 1010 is but a single frame (i.e. the frame layout of Fig. 4A). Using the 
shared whiteboard, the client and specialist can exchange notes and diagrams . This frame 1102 
contain a Web page having information on Adapt/X products. Shared pointer 1103 can also be 
implemented so that the guide can elaborate on a question from the client. The guide can tell the 
client to "click here" via the whiteboard method for ftirther information as depicted at 1 104 and can 
circle a feature of the Web page, as shown at 1 106, and write that these are "target Ads" in response 
to a question posed by a client using the whiteboard method. Further discussion the Whiteboard is 
found at column 32, line 42, through column 33, line 32. This discussion documents the fact that the 
Whiteboard can be a transparent overlay on a frame displaying an html page provided by HTTP 
server 1204 of Fig. 12, that lines can be drawn on one client, and that conmiends corresponding to 
the drawn line will be forwarded to all of the other users. 

Thus, there is not a single word within the four comers of the '991 patent regarding 
generating an "active hyperlink object" using a Whiteboard. In fact, there is no discussion regarding 
generating an "active hyperlink object" anywhere in the '991 patent. 

With respect to the recited transmitting step, the '991 patent clearly does not transmit "all of 
the generated . . . objects," since the '991 patent does not disclose transmitting an object, i.e., the 
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active hyperlink object, not generated by the '991 patent. As discussed above, the '991 patent 
discloses transmitting commands, the line drawing command illustrated in Fig. 39, and not the line, 
i.e., the object, itself. Moreover, assuming arguendo the piper server 502 receives all objects, which 
is clearly not the case, the piper server 502 is incapable of selective transmission to these objects to 
other clients 1208 participating in the session. 

With respect to the accumulating step, since the '99 1 patent does not disclose the transmitting 
step of claim 1, i.e., the '991 patent does not transmit the generated objects, the *991 patent cannot 
disclose the recited accumulating step. 

With respect to the filtering step, it is respectfully submitted that there is not one word within 
the four comers of the '991 patent that discloses or even suggests a filtering step. All of the session 
clients. Le.. the users collaborating with one another, coupled to the piper server 502 receive 
exactly the same information . See col. 29, line 6, through col. 30, line 3. See also the discussion 
above regarding the preamble language. 

For all of the reasons given above, the Examiner is respectfully requested to reconsider and 
withdraw the 35 U.S.C. § 1 02(e) rejection of claim 1 . Claims 2-4 depending from independent claim 
1 , are allowable for all of the reasons given with respect to claim 1 . 

It is also respectfully submitted that independent claims 5 and 13 distinguish over the '991 
patent for all of the reasons noted with respect to claim 1. Moreover, claims 5 and 13 distinguish 
even further over the applied reference by virtue the of the recitation of "generating ... a moving track 
object," which is completely missing from the '991 patent. Thus, the Examiner is respectfully 
requested to reconsider the 35 U.S.C. §102(e) rejection of claims 5 and 13 for all of the reasons 
numerated above. Claims 6-12 and 14-21, depending from claims 5 and 13, respectively, are 
allowable for all of the reasons given with respect to claims 5 and 13. 

In short, independent claims 1 , 5 and 1 3 recite generating objects, i.e., active hyperlink and/or 
active track objects. In contrast, the '991 patent does not disclose or suggest generation of this(ese) 
obj ect(s) anywhere within the four comers of the ' 99 1 patent. Thus, the ' 99 1 patent cannot anticipate 
the invention recited in claims 1, 5 and 13. Moreover, and in any event, the '991 patent does not 
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disclose or suggest a step for "filtering the predetermined, the active hyperlink, the text, and the 
freehand drawing objects to thereby permit selective retransmission of the predetermined, the active 
hyperlink, the text, and the freehand drawing objects to respective ones of the other users ." In other 
words, all of the objects generated by a first of several users need not be transmitted to all of the 
other users collaborating with the first user. Since all of claims 1,5, and 1 3 positively recite this step, 
and since there is no structure or software disclosed in the '991 patent capable of performing such 
a step, the '991 patent cannot possibly anticipate the invention recited in claims 1, 5, and 13. 

In light of the amendments and remarks presented above, it is respectfully submitted that the 
application is in condition for allowance, and such action is hereby solicited. 

By this response, Applicant has made a sincere effort to place this case in final condition for 
allowance. However, if it is deemed that there still remain additional issues to be resolved, the 
Examiner is encouraged to call the Applicant's undersigned representative prior to taking any fiirther 
formal action in this case. 



Respectfiilly submitted. 




^ames B. Bechtel 
Reg. No. 29,890 
Phone: (540) 653-8061 



Date: July 25, 2002 
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